A domain-specific language (DSL) is a software programming language dedicated to a particular domain or problem. Such languages provide abstractions and notations appropriate to a particular domain and are usually small, more declarative than imperative, and less expressive than a general-purpose language (GPL). For example, a language for specifying business rules might include abstractions like Rule and Condition. An appropriate DSL makes it easier for a user to define or solve a problem in that domain.
However, due to the specialized nature of DSLs, it is often necessary to combine a DSL with another programming language in order to fully specify a solution to a problem. For example, the Business Process Execution Language (BPEL) is a DSL for web-service scripting. Within a BPEL specification an additional language is used for specific data modification and logical expressions. Such an additional language is the Java programming language (Java is a registered trademark of Sun Microsystems Inc.).
Domain specific languages are commonly defined using a language definition standard known as the Meta-Object Facility (MOF) from the Object Management Group (OMG) (OMG and MOF are trademarks of the Object Management Group). A full and formal specification of MOF is available from the OMG at www.omg.org/docs/formal/02-04-03.pdf (Meta Object Facility Specification, Version 1.4, April 2002). The MOF standard provides a technique for specifying an abstract syntax (set of concepts) and a textual concrete syntax for a language. In the abstract syntax, an expression consisting of an expression body in string form and a language identifier can be used to allow arbitrary extensions in other programming languages to be used. Such an arrangement is illustrated in FIG. 1, and is described below.
FIG. 1 is a block diagram of an application MOF model 100 in the prior art, such as a MOF model of a domain specific language. The MOF model 100 includes one or more packages 102. In a MOF model, a package 102 is a container for classifiers including, for example, a class 106 and/or a data types 104. The class 106 is a defined structure which can be instantiated into corresponding objects. The data type 104 has no predefined structure, and can be instantiated to have a particular data value. MOF model 100 can also include expression 108. Expression 108 is an abstract expression consisting of a language identifier 110 for the expression (such as an identification of the Java language), and an expression body 112. Expression body 112 is a string representation of the expression. For example, the expression body can be an assignment expression such as “a=x”, a mathematical expression such as “a=2y+4”, or any other conceivable expression in the language identified by the language identifier 110. Expression body 112 could further be an entire subroutine, method, function, or procedure, although the expression body 112 is always represented in string form.
In use, the MOF model 100 is parsed by parser 120. The parser 120 can be an interpreter capable of interpreting the specification of the MOF model 100 and generating an application runtime 122 which is capable of actual execution on a computer system. Alternatively, the parser 120 can be a compiler. Parser 120 draws upon a MOF implementation 114 which includes base classes 116 which may be required to fully implement the application runtime 122. For example, base classes 116 might include fundamental functionality, data conversion, arithmetic operations, and the like. Further, it is necessary for the parser 120 to employ an expression language application programming interface (API) 118. The expression language API 118 provides facilities for the conversion of expression 108 into a runnable expression. For example, the expression language API 118 can provide an expression statement interpreter which parses the expression body 112 using a programming language identified by the language identifier 110 in order to generate an executable form of the expression 112. If the language identifier 110 indicates that the expression 108 is a Java expression, the expression language API 118 can employ a Java interpreter to generate an executable form of the expression 112 accordingly. In an alternative implementation, an expression language importer is used in place of the expression language API 118 to undertake the same function.
Thus MOF provides an extension mechanism through the definition of expressions having an expression language identifier and an expression body. However, for such extensions to be usable in the generation of an implementation of a MOF model, it is necessary for an implementer of the MOF model to provide the expression language API or an expression language importer in order that the meaning of an expression can be appropriately interpreted. There is currently no standard way to achieve this without the addition of nonstandard additional programming interfaces or importers.
Thus it would be advantageous to provide a mechanism for allowing new expression languages to be plugged in to a DSL which is defined using the MOF standard without the need for an API or expression language importer to support such new expression languages.